🔒 全面加固跨世界 GM RPC、用户脚本、Sandbox 与 Agent 边界 - #1747

有冲突需要解决一下

好。我处理一下

冲突已解决

复现出几个非常严重不能接受的问题：SW回收和更新脚本后，不刷新页面，脚本就无法正常使用了，会报错："page execution binding is invalid"

这个PR已经不是人力可以弄的了，太头疼了

Review：真实浏览器验证发现的问题

验证基于当前 head 596e2506，与 main d8c1d79d 构建出的扩展做对照：用同一套脚本在 Chromium 里分别跑，表中的「base 正常 / PR 异常」都是实测结果。🔴 标注的是合并前必须修复的严重问题。CI 全绿，是因为现有 E2E 没有覆盖 SW 重启、脚本更新后旧页面继续调用 GM、大对象存储这几种情况。

🔴 1. SW 被回收后，GM 和脚本注入出问题（阻塞）

复现时直接启动 Chrome，不在 SW 上挂调试器，让它自然空闲回收（约 31–33 秒）：

复现步骤：

1. 关闭「保持后台运行」，也不要打开 SW 的 DevTools。
2. 新装或更新一个脚本，打开匹配页面，确认脚本在运行。
3. 什么都不操作，等到 chrome://serviceworker-internals 显示 SW 为 STOPPED（也可以直接点 Stop）。
4. 在原页面里调用 GM，会失败；新开一个匹配页面，新装的脚本不会运行。

这里其实是两个独立的问题。

1a. scriptRevision 的值取决于对象键的顺序

getCompiledScriptRevision 对 JSON.stringify({compiledCode, metadata, …}) 求 SHA-256，early-start 的编译产物里还嵌入了 JSON.stringify(scriptInfo)。

问题在于键的顺序不固定：从 chrome.storage 读回的对象，键按字母序排列；安装或更新时内存里的对象，键保持解析时的插入顺序。实测同一个脚本，从内存缓存取出时 metadata 的键是 name, namespace, version, match, grant，从 storage 原样读出时是 grant, match, name, namespace, version，两者算出的 revision 不同（39086a1c… 对比 08100369…）。

SW 重启后 pageLoadCaches 是空的，runtime.ts:2509-2511 会用重新算出的 revision 去和存储里的比较，对不上就把这个脚本丢掉，于是 getScriptsForTab 返回 null，页面拿到 {ok:false}。冷启动时会用 storage 里的对象重建一遍，所以浏览器重启后又能恢复。

修复：在 buildCompiledResourceFromScript 入口处先把 metadata 规范化。我在本地按下面的改法验证过，SW 自然回收后，普通脚本和 early-start 脚本在新标签页都能正常运行；runtime、utils、gm_api 等 6 个相关测试文件共 329 个用例通过。

const sortKeys = <T extends Record<string, any> | undefined>(m: T): T =>
  m && (Object.fromEntries(Object.keys(m).sort().map((k) => [k, m[k]])) as T);
script = { ...script, metadata: sortKeys(script.metadata), selfMetadata: sortKeys(script.selfMetadata) };

更彻底的做法是：revision 只对规范化后的源输入求哈希（代码、metadata、匹配规则、资源，加上编译器版本），不再对编译产物求哈希。同时建议补一个单测，断言键顺序不同的同一个脚本得到相同的 revision。

1b. execution binding 只保存在 SW 内存里

pageExecutionBindings 只存在于内存中（runtime.ts:202），没有持久化，也没有重新签发的路径。所以 SW 一旦重启，所有已打开页面的 GM 调用都会报 page execution binding is invalid。

建议把 handle 改成签名令牌：会话密钥放在 chrome.storage.session（SW 重启后仍在），handle 用 HMAC 签名 {tabId, frameId, documentId, uuid, envTag, grants}。内存里的 Map 降级为缓存，查不到时验签，再根据真实 sender 和脚本当前状态重建 binding。代价是 SW 重启后请求序号窗口会被重置。

🔴 2. 脚本更新后，已打开页面的 GM 调用全部失败（阻塞）

先打开页面让脚本执行，然后更新这个脚本，再在页面里调用 GM，会报 page execution binding is invalid；base 下旧实例可以继续工作。原因是 installScript 会调用 revokePageBindingsForScript。另外从代码看，启用开关、黑名单修改和全局开关也会撤销 binding（runtime.ts:1313/1615），这几条没有实测。

建议采用 1b 的签名令牌方案后不再整体撤销，策略改为：

• 脚本被删除或禁用：旧实例失效。
• 脚本被更新：旧实例继续可用，权限取令牌里的旧 grants 与新 grants 的交集。

这样既保留了 base 的使用体验，也满足「旧 wrapper 不能获得新权限」的目标。

🔴 3. 大对象 GM 读写的性能严重退化（阻塞）

在浏览器里实测，对象有 2 万条记录：

原因是 customClone（global.ts:114-179）对每个对象节点，都会先分别调用 Map.prototype.forEach 和 Set.prototype.forEach 做试探，每个节点因此抛出并捕获两次异常。GM_getValue 和 valueUpdate（新旧值各一次）都会经过这里。

修复：普通对象或数组不可能是 Map/Set，可以直接跳过这两次探测：

const proto = Native.objectGetPrototypeOf(value);
const plain = proto === Object.prototype || proto === null || Native.arrayIsArray(value);
if (!plain) try { /* Map 探测 */ } catch {}
if (!plain) try { /* Set 探测 */ } catch {}

在同一个进程里对比，复制 2 万条记录的对象：base 7–25ms，PR 356–534ms，改后 15–22ms。小对象从 28–46µs 降到 2µs。改后的输出与 PR 版完全一致，带 getter 的对象仍然会被拒绝。

更进一步：GM_getValue 读的是扩展自己存储的、已经规范化过的数据，可以直接用 structuredClone，不需要再做 data-only 校验。

🔴 4. NaN/±Infinity 既存不住，还会让整批值变更被丢弃（阻塞）

• 执行 GM_setValues({a: Infinity, b: 1}) 后，所有标签页（包括写入方自己）都不会触发 b 的监听器。原因是接收端的 isEncodedValue（script_runtime.ts:105）只认得 RType 0/1/2，不认识新加的 3/4/5，于是整个 update 被丢弃。
• 更根本的问题是 chrome.storage.local 存不下这些值。直接写入 {a: Infinity, b: NaN}，读回来这两个 key 都不见了。脚本里调用 GM_setValue("inf", Infinity) 后，ValueDAO 落盘的数据里也没有这个 key。所以 PR 描述里的「无损往返」只在 SW 内存里成立，SW 重启、浏览器重启、备份、同步之后都会丢失。现有 E2E 只刷新页面，不会重启 SW，所以测不出来。

建议在存储规范化阶段把非有限数按 JSON 语义转成 null，并删除 RType 3/4/5。

5. Date 被存成 {}（行为变更，需要确认）

GM_setValue("d", new Date(0)) 之后，PR 当场读回和刷新后读回都是 {}；base 是 "1970-01-01T00:00:00.000Z"。测试里按 Tampermonkey 的行为固定成了 {}，但这会破坏现有依赖 base 和 Violentmonkey 行为的脚本。建议对带 toJSON 的对象调用它。

6. 不属于任何标签页的 frame 不再注入脚本（静态分析）

issuePageBinding（runtime.ts:600）在没有 tab 时会直接抛错，导致整个 pageLoad 失败。这与 #1783「脚本照常下发」的行为冲突，runtime.ts:2145 那条注释也因此不再成立。建议没有 tab 时用 documentId 作为绑定键。这种场景在自动化环境里构造不出来，所以没有实测。

7. XHR 出错时 onloadend 的字段被改坏

请求出错后，onloadend 收到的是 readyState 0，finalUrl 和 headers 为空；base 是 readyState 4，finalUrl 也在。原因是合成的 loadend（gm_xhr.ts:582-591）先于 broker 的真实 loadend 发出，后者随即被丢掉。建议合成事件沿用 onerror 那次的响应字段，或者只在连接关闭、且始终没收到 broker 的 loadend 时才补发。

其他

• 体积和启动延迟：content.js 和 inject.js 各增大约 36%，scripting.js 增大约 60%。10 个 document-start 脚本中最晚的启动时间从约 47ms 增加到约 53ms。
• content 世界的日志会丢失：content.ts:30 通过 ExtensionMessage 发送 scripting/logger，SW 不处理这个前缀。
• 只做了静态分析、未实测的点：BFCache 后退恢复会丢失 binding；Firefox 没有 documentId 时按 URL 校验，pushState 之后可能失败；iframe 频繁替换时 SW 内的状态会持续累积。
• 范围：这个 PR 包含 248 个 commit、150 个文件，混入了 vitest 基础设施修复、与主题无关的文档改动，以及死代码（WindowMessage 类、node-worker-threads 回退分支、拼错文件名的 mesasge-channel.ts）。AGENTS.md 里仍写着 Offscreen ↔ Sandbox 走 WindowMessage，PR 描述里的 head（cc195781）也已过期。建议拆分：XHR 收尾、值同步协议、MAIN 世界传输、Agent owner 校验各自独立成 PR，并各自补上 SW 重启和脚本更新场景的 E2E。

...看來還有一段路要走
角度不同，關注內容也不一樣
要每個角度都看清楚